Field of the Invention
This invention relates to Location Based Services (LBS), Assisted Global Positioning System (A-GPS), and Secure User Plane Location (SUPL) services.
Background of Related Art
For a mobile device whose current position is requested, multiple messages are exchanged over an Internet Protocol (IP) network. Messages are passed between the mobile device and a location server to determine the location of the mobile device.
However, in a distributed server environment, current IP based location services systems do not provide a secure and consistent method to allow messages belonging to the same location request to be routed to the correct server. In this environment, messages belonging to the same location session are not guaranteed to be routed to the correct server that initiated the session, often resulting in failed location requests. No conventional system is known to provide a standard and efficient method to manage location sessions in a distributed server environment.
One possible method to correctly route a message when an unsolicited (stray) message is received in one of the distributed servers would be to broadcast to all servers in a distributed server network. However, this would be brute-force and wasteful of communication and processing resources. Moreover, the number of broadcast messages would grow exponentially as the number of distributed servers increases.
Secure User Plane Location (SUPL) is a standards-based protocol that has been developed to allow a mobile handset client to communicate with a location server. The SUPL specification is defined by the Open Mobile Alliance (OMA) standards working group. Refer to OMA Secure User Plane Location Architecture document, OMA-AD-SUPL-V1.sub.--0-20060127-C for more details on OMA SUPL call flows; and OMA User Plane Location Protocol document, OMA-TS-U LP-V1.sub.--0-20060127-C.
The OMA SUPL Version 1 specifies the following basic call flows: (1) SUPL network initiated (NI) call flow, and (2) SUPL SET initiated (SI) call flow. FIG. 9 shows typical OMA mobile terminated call flow for a SUPL location request.
In particular, as shown in FIG. 9, messages are passed between a SUPL agent 802 residing in the network, a satellite reference server 804, a SUPL server 806, a PPG 808, and a SUPL Enabled Terminal (SET) 812.
The SUPL server (or SLP) 806 comprises a SUPL Location Center (SLC) and SUPL Positioning Center (SPC). A mobile device is generalized as a SUPL Enabled Terminal (SET) 812. The SLC coordinates operations of SUPL communications in the network, and communicates with the SPC component. The SPC Provides GPS assistance data to the SET 812, and performs precise position calculation of a SET 812.
The SLP can operate in either Proxy or Non-Proxy. In the Proxy Mode, the SET communicates with the SPC using the SLC as a proxy during a precise location fix calculation, whereas in the Non-Proxy Mode, the SPC communicates with the SET directly to perform the precise position calculation.
As shown in FIG. 9, a call flow routing problem exists in network initiated SUPL positioning requests. For instance, network initiated location requests 820 arrive at the SUPL server 806 via an MLP interface. The SUPL server 806 processing this network initiated request is required to send a trigger message (SUPL INIT message) 822 to the SET 812 for validating and initiating a SUPL positioning session 828. The trigger message 822 is sent to the SET 812 as a push message 824 from the PPG 808 (or as an SMS message from an SMSC/MC). At that point, the SET 812 needs to establish a secure TCP/IP connection to the SUPL server 806 to respond to the SUPL positioning request.
However, when a wireless provider has multiple SUPL servers in an active-active configuration for redundancy, the connection request from the SET 812 may be established with a SUPL server that did not initiate this transaction. This can result in positioning request timeout or termination.
Although the OMA User Plane Location Protocol specification (Refer to OMA User Plane Location Protocol document, OMA-TS-ULP-V1.sub.--0-20060127-C) defines fields within the SUPL INIT message 822 that can be used for routing incoming SUPL messages from the SET 812, there are loopholes that can result in a routing failure. According to the SUPL standard, a session ID is a unique value consisting of two parts: the server portion (SLP Session ID) and the handset portion (SET Session ID). The SLP 806 can specify its address within the SLP Session ID parameter and also within an optional “SLP Address” field of the ULP SUPL INIT message. Nevertheless, routing can fail because of the following potential reasons: First, the “SLP Address” field is optional for Proxy mode, and SLP vendors may choose not to use it. Second, some SUPL server vendors might include a public FQDN in the SLP Session ID that cannot be resolved for routing to a specific SUPL server instance. Moreover, the SET 812 can choose to ignore the value of the “SLP Address” field of SUPL INIT message in favor of a pre-provisioned SUPL server address in the SET. Furthermore, the SUPL server 806 might specify its own local interface address in the “SLP Address” or “SLP Session Id” field, but since it might be its address within a Virtual LAN, it is not guaranteed to be unique across the carrier's geo-diverse network.
The problem may not be visible if the carrier is using only a single SUPL server 806, but generally this is not the case. Typically a wireless carrier has multiple geo-diverse SUPL servers for load sharing, redundancy and ensuring service availability. When the SET 812 connects to a SUPL server 806 using FQDN or a pre-provisioned well known SLP address, a switch/router within the carrier's networks attempts to resolve the request to a specific SUPL server instance. However, there is a probability that the SUPL server that receives the request from the SET might not be the initiator of the SUPL positioning session, thus causing many network initiated positioning requests to fail, timeout or to result in undefined behavior.
One unexpected behavior of the above problem where the privacy of a subscriber can be compromised is when the SUPL server 806 already has a cached position and tries to obtain consent from the SET 812 for returning the cached position to the external SUPL agent 802. If the notification and verification type at SLP 806 is set to “allowed on no answer” and the SET consent denial message fails to reach the proper SUPL server 806, the SLP 806 may disclose the cached SET position to a unauthorized external entity.